1. Field of the Invention
The invention relates to techniques for carrying messages of one protocol over networks of a different protocol. More particularly, the invention involves a technique for carrying messages of a connectionless protocol, such as IP over Ethernet, over a connection-oriented network, such as an ATM network.
2. Description of Related Art
The various nodes or network elements (NE""s) of a computer data network communicate with each other via commonly agreed upon communication protocols. These protocols have different layers or levels, each defining a different aspect of the protocol. Each different layer can be thought of as a sub-protocol of the overall protocol, but can also be thought of as a protocol in itself. All of the sub-protocols which together define an overall protocol are often referred to as a xe2x80x9cprotocol stackxe2x80x9d. The interface between the different layers of a stack are well-defined, so different alternative sub-protocols can be substituted for other sub-protocols at the same layer in the stack.
One very common protocol used for computer networking is the so-called Internetworking Protocol (IP). IP is a network layer service and includes provisions for addressing, type-of-service specification, fragmentation and reassembly, and security information. It is defined- in a series of documents maintained by the Internet Engineering Task Force (IETF), most notably, J. Postel, xe2x80x9cInternet Protocol,xe2x80x9d STD0005 (September 1981) (including RFC0791, RFC0950, RFC0919, RFC0922, RFC792, RFC1112), incorporated herein by reference. IP defines a protocol to be used at one layer of the overall communication protocol, specifically the xe2x80x9cnetworkxe2x80x9d protocol layer. Several common alternative network-level protocols are IPX (defined in Novell, Inc., xe2x80x9cAdvanced NetWare V2.1 Internetwork Packet Exchange Protocol (IPX) with Asynchronous Event Scheduler (AES)xe2x80x9d, October 1986, incorporated by reference herein); DECnet; and Xerox PUP. Many modern local area networks (LANs) use an Ethernet protocol as the next layer below IP. Ethernet includes a Media Access Control (MAC) layer protocol, and is defined in IEEE, xe2x80x9cIEEE Standards for Local Area Networks: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specificationsxe2x80x9d (IEEE Standard No. 802.3) (1985), incorporated herein by reference. When IP and Ethernet are used together in a protocol stack, the combined protocol is sometimes referred to herein as xe2x80x9cIP over Ethernetxe2x80x9d. Similarly, when IPX, DECnet or Xerox PUP are carried over Ethernet, the combined stack is sometimes referred to herein as xe2x80x9cIPX over Ethernetxe2x80x9d, xe2x80x9cDECnet over Ethernetxe2x80x9d and xe2x80x9cPUP over Ethernetxe2x80x9d, respectively.
The basic unit of data at the network layer is often referred to as a xe2x80x9cdatagramxe2x80x9d (e.g. an xe2x80x9cIP datagramxe2x80x9d), whereas the basic unit of data at the MAC level is often referred to as a xe2x80x9cpacketxe2x80x9d (as in xe2x80x9cEthernet packetxe2x80x9d). Datagrams must be xe2x80x9cencapsulatedxe2x80x9d according to the MAC level protocol in order to be transmitted, which may involve breaking them up into multiple packets. Similarly, the recipient node must extract and re-assemble the datagram from one or more MAC level packets in order to make use of it. Also as used herein, a xe2x80x9cmessagexe2x80x9d is a logical data unit that is not intended to imply any particular encapsulation. Some messages are bigger than a datagram, in which case they need to be divided up into multiple datagrams (and then multiple packets) in order to be transmitted. Other messages consist of a single packet, such as an ARP Request packet.
Wide Area Networks (WANs) typically take advantage of existing communications media for carrying messages over great distances. In particular, usually, the different nodes of a WAN communicate with each other via existing telephony networks such as Integrated Services Digital Networks (ISDN) or Broadband ISDN (B-ISDN). Very often, the telephony network is used to connect a subscriber""s data network to an Internet Service Provider (ISP), or a subscriber""s home office network to his or her central office network. ISDN and B-ISDN networks have their own protocols for transmitting messages, and when two computer networks need to communicate with each other via a telephony communications path, adapters are usually necessary on both ends of the telephony network to convert messages from a computer networking protocol to an ISDN or B-ISDN protocol and vice-versa.
Telephony protocols, having been designed historically for voice traffic (i.e., telephone calls), are usually connection-oriented protocols. That is, they proceed first with a set-up phase, in which a calling party specifies the xe2x80x9caddressxe2x80x9d (e.g., phone number) of a called party, and the network establishes a xe2x80x9cconnectionxe2x80x9d between them. All subsequent communication between the two parties then takes place via the established connection, and no further addressing is needed. At the conclusion of the conversation, the connection is released, or xe2x80x9ctorn downxe2x80x9d, releasing the telephony network resources for other connections. Connection-oriented networks and protocols are most cost effective in situations where it is expected that one node will communicate with a second node for a fairly lengthy period of time. Such protocols assume that it is less expensive to take the time and resources for a connection set-up phase than it would cost to examine and properly forward individually addressed message units which, at least for voice traffic, are all likely to be addressed to the same destination for a long period of time.
Computer data communication protocols, on the other hand, are often connectionless protocols, at least at the lowest levels. That is, no xe2x80x9cconnectionxe2x80x9d is established between the two communicating nodes at these protocol levels; rather, each message unit contains the address of its destination. Each node that receives packets examines the destination address of the packet in order to determine whether to take or ignore the packet. Connectionless protocols, sometimes also called packet-switched protocols, are most cost effective in computer data networks because traffic in such networks typically consists of numerous messages directed to many different destinations, with a lengthy communication to a single destination taking place only rarely.
Note that a given protocol stack can be connection-oriented or connectionless at different levels. It is even possible for a protocol stack to be connection-oriented at two different layers and connectionless at an intermediate layer, or vice versa. IP and IPX over Ethernet are both connectionless, for example, although higher levels in the stack might well be connection-oriented.
One commonly used connection-oriented protocol is known as ATM (Asynchronous Transfer Mode), defined in a number of specifications published by the ATM Forum, including: ATM Forum, xe2x80x9cATM User-Network Interface Specification Version 3.1,xe2x80x9d ATM Forum, Mountain View, California (September, 1994) (xe2x80x9cUNI 3.1xe2x80x9d); ATM Forum, xe2x80x9cATM User-Network Interface (UNI) Signaling Specification Version 4.0,xe2x80x9d ATM Forum, Mountain View, California (July 1996) (xe2x80x9cUNI 4.0xe2x80x9d); and International Telecommunication Union, xe2x80x9cBroadband Integrated Services Digital Network (B-ISDN)xe2x80x94Digital Subscribers Signaling System No. 2 (DSS 2)xe2x80x94User-Network Interface (UNI) Layer 3 Specification for Basic Call/Connection Control,xe2x80x9d ITU-T recommendation Q.2931 (February 1995) (xe2x80x9cQ.2931xe2x80x9d), all incorporated by reference herein. The term xe2x80x9cATM network,xe2x80x9d as used herein, refers to a network that conforms to these documents in all relevant respects, whether or not it also conforms to more recent or other specifications as well.
When two parties wish to communicate over a connection-oriented network such as an ATM network, the network establishes a connection from the xe2x80x9cpoint of presencexe2x80x9d (or xe2x80x9cendpointxe2x80x9d) on the connection-oriented-network, through which a first device (e.g. a telephone or a host computer) reaches the network, to the xe2x80x9cpoint of presencexe2x80x9d (or xe2x80x9cendpointxe2x80x9d) on the connection-oriented network through which the second or destination device can be reached. For data connections, for example, each such endpoint on the connection-oriented network has an xe2x80x9cadapterxe2x80x9d which interfaces the connection-oriented network protocol, on one hand, to the data protocol, on the other hand. Such an adapter may be located entirely within a host computer which is itself an endpoint for data communications, in which case the host computer is referred to herein as an xe2x80x9cendsystemxe2x80x9d of the connection-oriented network and the xe2x80x9cadapterxe2x80x9d comprises a level of software in the host computer""s protocol stack (below the MAC layer). Alternatively, the adapter may be located within a termination unit of the connection-oriented network, which termination unit is connected on one side to the connection-oriented network and on the other side to a computer data network. The ultimate endpoint for the data communication is located in another node on the computer data network. In this alternative, the xe2x80x9cadapterxe2x80x9d still comprises a layer of software in a protocol stack, but the protocol stack typically extends only as high as the MAC layer or the network layer. If the protocol stack on the termination unit extends only as high as the MAC layer, then the unit is viewed from the data network as a xe2x80x9cbridgexe2x80x9d, also called a bridging network element (BNE). If the protocol stack on the termination unit extends as high as the network layer, then the unit is viewed from the data network as a xe2x80x9crouterxe2x80x9d, also called a routing network element.
When an adapter accepts a packet from a computer data network, the adapter needs to be able to determine whether to transmit it on the connection-oriented network over an existing connection or to create a new connection, and if the latter, which connection-oriented network endpoint to target and what parameters should be used in the new connection. More specifically with respect to a bridging or routing ATM adapter, the adapter needs to be able to determine whether the destination MAC or IP address is reachable via an existing ATM virtual connection (VC) and, if so, which one. If the destination node is not reachable via existing VC""s, the adapter needs to be able to determine whether the destination is reachable at all over the ATM network, and if so, what ATM address, quality of service, security parameters and other parameters to use in establishing a new VC. These issues are addressed partially in several internet-related documents proposing standards for the transmission of IP datagrams over ATM networks. Such documents include the following, all incorporated by reference herein:
M. Laubach, xe2x80x9cClassical IP and ARP over ATM,xe2x80x9d Request for Comments No. 1577 (1994) (xe2x80x9cRFC 1577xe2x80x9d)
M. Perez, xe2x80x9cATM Signaling Support for IP over ATM,xe2x80x9d Request for Comments No. 1755 (1995) (xe2x80x9cRFC 1755xe2x80x9d)
M. Maher, xe2x80x9cATM Signalling Support for IP over ATMxe2x80x94UNI 4.0 Update,xe2x80x9d file draft-ietf-ion-sig-uni4.0-02.txt (March 1997) (xe2x80x9cUNI 4.0 Updatexe2x80x9d)
Heinanen, xe2x80x9cMultiprotocol Encapsulation over ATM Adaptation Layer 5,xe2x80x9d Request for Comments No. 1483 (1993) (xe2x80x9cRFC 1483xe2x80x9d)
The above documents mostly assume a network architecture having a plurality of ATM endpoints, each of which has an adapter which interfaces the ATM endpoint with an IP (or other network layer) protocol stack. According to the documents, each ATM adapter maintains a map indicating which IP addresses are reachable via each VC that it has. ATM adapters are also permitted to maintain a cache of recently confirmed IP-to-ATM address translations, whether or not they are reachable on any current VC. When an IP client (software or hardware) directs an IP packet to an IP destination, and it is accepted by the ATM adapter, then the adapter encapsulates it according to a predefined ATM protocol (know as AAL5) and sends it on via an existing VC to the ATM adapter through which the destination IP address can be reached. If no VC is currently established between these adapters, then the originating adapter checks its local cache of IP-to-ATM address translations for the address of a destination ATM adapter through which the destination IP address can be reached, and if present and valid, xe2x80x9ccallsxe2x80x9d the destination adapter to set up a new Switched Virtual Circuit (SVC) before transmitting data. If the desired IP-to-ATM address translation is absent or invalid in the local cache, then the ATM adapter uses an ATM Address Resolution Protocol (ATMARP) protocol to request the translation. According to this protocol, the ATM adapter creates an ATMARP request encapsulated in an ATM cell, containing the desired destination IP address, and sends it to a so-called ATMARP server on the ATM network. The ATM adapter uses a pre-provisioned (or at least pre-identified) point-to-point ATM connection to transmit the ATMARP request. The ATMARP server then examines its own cache of IP-to-ATM address translations, and returns an ATMARP reply message specifying the ATM address through which the destination IP address can be reached. The originating ATM adapter adds the translation to its local cache, xe2x80x9ccallsxe2x80x9d the destination ATM adapter, and proceeds to transmit data on the resulting SVC.
One significant problem with the techniques of the above described documents is that they are expensive to implement in an ATM adapter. Ideally, ATM adapters should be low cost, relatively simple devices which do not do much more than interface between ATM on one side and the data network protocol on the other side. Requiring the ATM adapter to also understand ATMARP and other similar protocols would likely increase both the cost and complexity of the unit.
A second major problem with the above techniques is that the process of transmitting ATMARP requests to an ATMARP server and awaiting a response, as well as the process of establishing a connection across the ATM network once the target ATM network address is known, can take a very long time, in data transmission terms. During this time, the client device (e.g., a host computer on the data network) that originated the data packets which instigated the new connection, has no way to know that a delay has occurred. Thus it continues to transmit data packets on the local data network typically at a high rate of speed. If the ATM adapter attempts to buffer the packets while it awaits completion of the SVC, the data storage requirements of the ATM adapter can become enormous, especially, for example, if the local data network operates at 100 Mb/s or more. Alternatively, the ATM adapter can ignore packets that it cannot buffer, in which case a requirement is imposed on higher level software in the originating host (or on a human user) to determine that packets were lost and to retransmit.
A second problem with the above techniques arises especially when the ATM network is a telephony ATM network. Such networks have been designed historically to carry primarily voice traffic. Voice calls typically last on the order of three to five minutes, and ATM networks have typically been built with the capacity to handle calls of approximately that duration. The capability of connecting data networks to a telephony ATM network, on the other hand, raises the spectre of many subscribers connecting to internet service providers (ISP""s) (or to private office LANs) over the ATM network. These kinds of connections typically last on the order of 20-30 minutes each, much longer than an average voice call. Most conventional telephony networks are not designed to handle such lengthy calls on a regular basis without seriously impacting the availability of telephony resources for other subscribers.
The invention solves the above problems regarding when and how to establish connections across a connection-oriented network for data traffic, in a manner that takes advantage of a known solution to the additional and separate problem of data communications over an ATM network, namely how to handle broadcast packets received over a LAN by a BNE for forwarding over the non-broadcast ATM network. The latter problem arises because data network protocols often include a xe2x80x9cbroadcastxe2x80x9d form of addressing, whereas ATM does not. In the Ethernet protocols, for example, certain kinds of data packets have no addressee or the addressee is unknown. Such is the case with IARP request packets, for example. In these kinds of data packets, the destination Ethernet address listed in the header of the packet is specified as all ones. Each node on a subnet which receives a broadcast packet is expected to determine for itself whether it should respond. Again in the case of IARP request packets, each node is expected to look inside the packet and determine whether its own IP address matches the IP address for which a corresponding MAC-level address is being requested. If so, then the node is expected to reply with an IARP reply packet. If not, then in most cases the node is expected to ignore the packet. (An exception is a node which is also an IARP server, which is expected to respond on behalf of the targeted device.)
The bridging network elements on a data network are not considered xe2x80x9cnodesxe2x80x9d for the purpose of replying to broadcast packets. Bridges are intended to make the physical media on both sides of the bridge appear as a single subnet. Thus, when a bridge receives a broadcast packet on one port, it merely copies it to the other port. With respect to the Internet address resolution protocol, many bridges attempt to improve scaling characteristics by capturing ARP packets and cacheing the content, so that the bridge can respond to future IARP requests for the same translation without having to pass the request onto other parts of the subnet. This technique is known as xe2x80x9cproxy ARPxe2x80x9d, because the bridge acts as a xe2x80x9cproxyxe2x80x9d for the true node in responding to the IARP request.
ATM networks, as mentioned above, do not support broadcast capability. That is, they do not natively support a convenient addressing mode by which a data unit can be translated to all points of presence on the ATM network. ATM does include a xe2x80x9cmulti-castxe2x80x9d capability, in which a single data unit can be transmitted to a pre-established group of more than one ATM endpoint, but it is implemented by simply replicating the data unit and transmitting it separately to all the targeted points of presence. The above-incorporated RFC 1483 document teaches that an ATM interface acting as a bridge must be able to xe2x80x9cfloodxe2x80x9d, that is, send the broadcast packet to all possible appropriate destinations. In the ATM environment, this means sending the packet through every relevant VC that it has. But if each recipient bridging network element abides by this rule and retransmits the packet through all of its own relevant VCs, and if each recipient of those transmissions retransits the packet through all of its relevant VCs, then it can be seen that such a flooding rule can easily result in a broadcast storm rippling through a good part of the ATM network.
The ATM Forum has developed a set of protocols (xe2x80x9cLAN-Exe2x80x9d) for emulation of Ethernet LANs over an ATM network, and these are described in several publicly available documents including ATM Forum, xe2x80x9cLAN Emulation Over ATM Version 1.0,xe2x80x9d ATM Forum, Mountain View, California (January 1995); LAN Emulation Client Management Specification Version 1.0 (September 1995); LAN Emulation Over ATM Version 1.0 Addendum (December, 1995); LAN Emulation Servers Management Specification 1.0 (March 1996), all incorporated by reference herein. These documents call for an ATM network supporting LAN emulation to include a centralized Broadcast and Unknown Server (BUS). When a LAN Emulation Client (LEC) receives a broadcast packet for forwarding onto the ATM network, the LEC does not xe2x80x9cflood.xe2x80x9d Instead, it forwards the broadcast packet only to the BUS for handling. The BUS may in turn flood, depending on the packet.
Roughly described, Applicants"" invention also involves the forwarding of broadcast-addressed packets on to a single controller for handling, at least to the extent of forwarding IARP request packets. In an implementation of the invention, the predefined controller can act as an IARP server and return an IARP reply packet if the desired information is available. More importantly, however, the controller also uses the IARP request message as a trigger for the establishment of a connection across the connection-oriented network to the appropriate destination.
More particularly, still roughly described, whenever a BNE receives an IARP request message on its data port for forwarding onto a connection-oriented network, instead of flooding, the BNE forwards the message to a predefined controller. The controller then regards the IARP message as a trigger, and in response thereto, causes the connection-oriented network to establish a virtual connection between the point-of-presence through which the BNE accesses the connection-oriented network, to the point-of-presence through which the destination data network address, as indicated in the IARP request message, can be reached.
Other aspects, features and advantages of the invention are set forth in more detail in the drawings, the claims and in the Detailed Description below.